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PREFACE 


This  seminar  was  proposed  during  the  78th  Data  Reduction  and  Computer 
Group  (DR&CG)  meeting  held  at  the  30th  Space  Wing,  Vandenberg  Air  Force 
Base,  California,  to  take  place  at  the  79th  or  80th  DR&CG  meeting.  During  the 
seminar,  it  was  recognized  that  changes  are  taking  place  rapidly  in  test  data 
reduction  methods.  At  issue  is  "quicker  tximaroimd  time,"  although  a  more 
correct  view  might  be  "test  data  reduction  on  demand."  With  modem  engineering 
workstations  which  are  improving  daily,  the  increased  power  of  personal  com¬ 
puters,  compact  disk-read-only  memory  (CD-ROMs),  laser  printers,  high-capacity 
hard  disks,  and  an  ever  increasing  arsenal  of  general  pmpose  software  capabili¬ 
ties,  support  requirements  for  data  analysis  and  display  can  be  obtained  at  a 
higher  level. 

With  such  support,  a  computer  system  can  be  tailored  to  fit  many  applica¬ 
tions  better  than  many  techniques  used  in  the  past  for  software  development, 
modification,  and  dieckout.  Processes  which  took  weeks,  months,  or  even  years 
now  take  hoxirs,  days,  and  weeks.  The  papers  presented  at  this  seminar  demon¬ 
strate  steps  taken  by  member  and  associate  member  representatives  to  take 
advantage  of  the  new  technologies. 
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Near  Real-Time  Data  Reduction 
AFDTC  Examples 


Authors:  Mr.  D.  Aaron  Coffman  Address:  646  CCSG/SCWS 

Ms.  Lynda  Davila  201  W  Eglin  Blvd  Suite  259 

Computer  Scientists  Eglin  AFB,FL  32542-6829 

Abstract 

Using  the  Radar  Warning  Receiver  (RWR)  and  INS/GPS  Operation  Concept  Demonstration 
(OCD)  test  programs  as  examples,  this  abstract  describes  the  test  data  processing  techniques 
and  methodologies  which  characterize  the  current  trend  toward  the  integration  of  real-time 
and  near  real-time  data  reduction.  Included  in  this  description  are  the  test  data  requirements, 
the  real-time  and  near  real-time  data  reduction  processes,  and  the  efficiencies  gained/value 
added  to  the  test  programs. 

RWR  Example 

The  Radar  Warning  Receiver  (RWR)  test  results  of  an  open  air  test  mission  are  needed  on 
the  same  day  of  the  mission.  To  achieve  this  goal,  the  entire  data  collection,  reduction, 
analysis,  and  reporting  cycle  must  be  optimized  and/or  automated. 

The  Mission  Analysis  and  Reporting  System  (MARS)  is  an  existing  custom-built  tool  for 
EW  mission  data  management,  analysis,  and  reporting.  In  its  current  state,  MARS  provides 
tools  to  retrieve,  display,  and  analyze  Electronic  Warfare  (EW)  performance  data  through  the 
user-friendly  Microsoft  Windows  interface.  In  support  of  EW  open  air  testing  of  RWR 
systems,  the  646CCSG  MARS  Team  has  underway  a  near  real-time  RWR  data  reduction 
initiative  to  provide  today's  test  results  today.  This  initiative  consists  of  two  parts:  to  collect 
and  process  the  test  data  as  close  to  real-time  as  possible  and  to  expand  MARS  to  provide 
(both  graphically  and  numerically)  Response/Ageout  Time,  DF  Error,  and  Range  Error 
Analysis. 

Open  air  RWR  testing  includes  the  real-time  collection  of  telemetered  RWR  data,  the  real¬ 
time  collection  of  microwaved  threat  system  data  from  a  multitude  of  threat  missile  and  gun 
systems,  and  the  real-time  collection  of  microwaved  time  space  position  information  (TSPI). 
To  bring  all  the  various  sources  of  test  data  into  a  dedicated  high  speed  processing 
environment,  an  extensive  hardware  integration  effort  is  currently  underway.  At  the 
completion  of  this  initiative,  there  will  be,  at  a  minimum,  the  integration  of  three  DEC  Alpha 
(DEC  3000  Model  500S  Advantage  Server)  processors:  one  for  telemetry  collection,  one  for 
Threat/TSPI  collection,  and  one  for  dedicated  EW  data  processing. 
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The  test  data  will  be  processed  near  real-time  pass  by  pass,  resulting  in  five  disk  files:  RWR 
Display  Data,  Mission  Pass  Start/Stop  Times,  Threat  Site  Activity,  Control  Radar  TSPI,  and 
Aircraft  Attitude  Data.  MARS  will  import  these  files  immediately  after  the  mission, 
enabling  the  Test  Engineer,  on  a  PC  at  his  desk,  to  quickly  analyze  the  results  from  that  day's 
mission. 


OCD  Example 

The  test  item  for  the  OCD  test  program  was  an  inert  GBU-15  with  the  standard  electro- 
optical  guidance  system  replaced  by  an  integrated  INS/GPS  guidance  system.  Test  data 
requirements  included  real-time  telemetry  and  TSPI  for  mission  analysis,  eight  separate 
quick-look  reports  immediately  following  mission  completion,  and  large  quantities  of  data 
within  four  hours  for  in-depth  analysis. 

Customized  real-time  software  enabled  the  analysts  to  monitor  the  weapon's  digital  data,  the 
aircraft's  telemetry,  and  radar  data  on  displays  located  in  the  Central  Control  Facility  mission 
control  rooms.  Hard  copies  of  the  displays  and  tailored  reports  were  available  immediately 
after  the  mission. 

The  follow-on  data  reduction  processes  were  automated  by  logging  all  raw  telemetry  and 
radar  data  to  disk  during  the  mission.  These  data  files  were  then  converted  by  menu-driven 
software  into  Dataprobe  format  and  stored  in  the  test  analyst's  disk  area  for  interactive 
analysis.  The  test  analyst  utilized  the  Dataprobe  software  executing  on  the  Eglin  Computer 
Network  (ECONET)  to  produce  final  reports. 

This  integrated  data  processing  approach  provided  customized  real-time  and  near  real-time 
data  products  to  the  test  customer  as  well  as  a  complete  data  set  available  for  in-depth 
interactive  analysis  within  four  hours.  Significant  savings  of  time  and  cost  were  realized 
when  compared  with  conventional  post  mission  data  reduction  procedures.  Key  elements  of 
the  process  were  the  utilization  of  real-time  software  to  produce  tailored  quick-look  reports, 
real-time  data  archival,  use  of  commercial-off-the-shelf  software  for  interactive  data 
analysis,  and  allowing  the  test  analysts  to  interact  during  the  data  reduction  process. 

Summary 

The  modem  test  scenario  must  include  three  elements:  real-time  collection  of  data, 
dedicated  near  real-time  processing  of  that  data,  and  a  tailored  personal  analysis  tool.  These 
near  real-time  data  reduction  initiatives  are  yet  another  advance  enabling  the  Air  Force 
Development  Test  Center  to  provide  today's  test  results  todayl 
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Test  Data  Logging 
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Interfaces  with  commercial  PC  software  packaoes 
(e.g.,  Excel,  Word) 
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Automation  of  conversion  process 
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•  Data  processed  to  identify/display  vibration  ARTEC  2400  1 

amplitude  and  frequency 


37 


DISPLAY 
SYSTEM  (DS) 


CDAPS  DATA  FLOW 


DATA  PROCESSING  &  ANALYSIS 

TYPICAL  CONFIGURATION 


z  X 


a. 

i 

a 


o  o 


UJ 


iij“  ± 


< 

cc 

o 

z 


CO 

LU 


CO 
CO 

Si 

£3 


U. 

u. 

O 


LU 

Z 


z 

o 


CO 

q: 

O  LU 


LU 


LU 


LU 

LU 

LU 

.J 

-J 

-J 

CD 

m 

ffl 

< 

< 

< 

X 

X 

X 

< 

< 

< 

> 

> 

> 

q: 

LU 

H 

lU 

^  LU  < 

gzS^ 

QO<Z 

LUq^’CO 

tpccco 
^  lUUJ 
coCiclO 

>0^0: 

^  CL 

<  oc  ^ 

LU  UJ  S  CC 

H  >  <  O 

CO  <  CO  LU 


0 

0 

0 

0 

0 

0 

CM 

CM 

CM 

o 

z 

cr 

o 


o 

LU 

z 


CD 

z 

CO 

CO 

LU 

o 

o 

QC 

a. 

LU 


000 

CM  CM  CM 


Li. 

Z  LU 

o  o 


“< 

0 

0 

0 

0 

0 

0  c 

D|  0 

(0 

z  £ 

0 

0 

10 

10 

ID 

0  c 

D  ID 

CM 

h* 

T— 

« 

q 

10 

CM 

q 

CD 

CM 

CM  C 

mI  CD 

CM 

Q 

LU 

COI 

>- 

Q 

< 

LU 

h- 

CO 


CO 

H 

z 

LU 

CD  O 
z  z 
< 
:e 

cc 

O 

LU 

cr 

LU 
Q. 


cc 

LU 

LU 

z 

3  CD 

<  z 

o  LU 

a 

>- 


:e 

Z) 

X 

< 

CM 


LU 

Q 

O 


!< 


§ 

o 

L~| 

2 

m 

CO 

< 

QC 

h" 


K 
Z 
m 

CO 

z 
< 
a: 

H 

D 
UJ  ± 
LU  O 

0-  z 

CO  UJ 

5 

o 


LU 

O 


CO 
K 

Z 
Z) 

CD 

z  z 

DC  I 

s  1 

z  O 

LU 

q: 

LU 
CL 


3 

X 

< 


LU 

a 

o 

S 


< 


D 

O 


>- 

Q 


CO 

LU 

CD 

< 

CD 


a 

LU 

LU 

CL 

CO 

X 

CD 


CO 
LU 

cc 

=> 

CO 
CO 
LU 
X 
CL 

LU? 
CO  < 
z  CL 

oSo 

C  I  < 

CD  o  2 

>  I  Q 


41 


688  AERODYNAMIC  (EXPANDABLE  TO  2000  PARAMETERS) 

1052  GENERAL  PURPOSE  (PRESSURES,  T  E  M  P  E  R  AT  U  R  E  ETC] 
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LONG  RANGE  INTEGRATED  SS/TRANSIENT/DYNAMIC 
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TYPICAL  ETF  ANALYSIS  AREA 
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TSPI  DATA  PROCESSOR  DEVELOPMENT 


Kenneth  J.  Williamson 

Air  Force  Wright  Laboratory/Armament  Directorate 
EgUn  Air  Force  Base,  Florida  32542 


ABSTRACT 

This  paper  describes  the  concepts  and  philosophies  used  by  the  Wright  Laboratory  Annament 
Directorate  Instrumentation  Technology  Branch  in  the  development  of  the  Time  Space  Position 
Information  (TSPI)  Data  Processor  (TDP).  The  TDP  will  provide  common  hardware  and  software 
for  real-time  Kalman  filtering  to  be  used  on  DoD  test  ranges.  The  design  will  allow  for  easy 
integration  of  the  TDP  with  existing  range  assets. 

1.  INTRODUCTION 

High  accuracy  Time-Space-Position-Information  (TSPI)  of  aircraft  and  released  munitions  is 
essential  data  for  all  flight  test  programs.  This  data  is  provided  by  TSPI  data  sources  (such  as  GPS, 
instrumentation  radars,  photo/  video-theodolites,  and  muitilateration  systems)  that  have  unique 
strengths  and  weaknesses.  It  would  be  highly  desirable  to  integrate  all  available  inputs  to  improve 
data  accuracy.  Kalman  filtering  is  a  proven  methodology  for  integrating  data  and  providing  optimal 
estimates.  Because  of  the  computational  burden  Kalman  filtering  imposes,  this  type  of  processing 
has  traditionally  been  used  as  a  post  flight  activity.  Some  real-time  Kalman  filter  systems  have 
utilized  multiple  general  purpose  machines;  however,  this  is  not  a  cost  effective  approach  in 
providing  optimal  TSPI  estimates.  These  large  systems  are  not  only  costly  to  implement  but  the 
associated  maintenance  and  facility  real  estate  add  to  that  cost.  With  the  rapid  increase  in 
computational  power  becoming  available  in  microprocessors,  the  ability  to  cost  effectively  provide 
real-time  optimal  TSPI  estimates  has  become  a  reality. 

The  TSPI  solution  will  support  real-time  evaluation  of  mission  activities  at  both  central  and 
remote  sites.  This  will  improve  the  utilization  and  quality  of  mission  time  on  the  test  range.  The 
filter  solution  from  integrated  multiple  sensors  will  also  provide  greater  safety,  improved  system  fault 
tolerance,  and  enhanced  sensor  slaving  by  the  use  of  velocity  and  acceleration  estimates.  The  TSPI 
Data  Processor  Program,  created  by  the  Instrumentation  Technology  branch  and  funded  by 
OSD/DDRE  to  develop  a  low  cost,  real-time  system  will  provide  high  accuracy  TSPI  estimates  for 
DoD  range  applications. 


2.  DEVELOPMENT  EFFORTS 

Several  concepts  were  initially  proposed  for  the  TSPI  Data  Processor.  One  concept  was  to  use 
special  purpose  Very  Large  Scale  Integrated  (VLSI)  chips  to  perform  the  computationally 
demanding  parts  of  the  Kalman  filtering  algorithms.  Because  of  the  high  costs  of  complex  circuit 
board  designs  and  limited  system  flexibility,  the  performance  improvement  was  not  justified.  These 
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factors  conveyed  the  need  to  develop  low  cost  systems  using  groups  of  microprocessors  to  achieve 
required  performance  levels.  Several  multi-processor  configurations  were  considered,  but  the 
INMOS  Transputer  offered  the  higher  cost-performance  ratio  and  the  ability  to  easily  interconnect 
transputers  for  parallel  processing.  (Ref  1.) 

The  transputer,  schematically  illustrated  in  figure  2-1,  is  a  high  performance  microprocessor 
developed  by  INMOS  Corporation.  The  architecture  is  similar  to  Reduced  Instruction  Set 
Computing  (RISC)  microprocessors,  but  the  presence  of  hardware  that  allows  the  interconnection 
of  transputers  through  high  speed  communication  links  makes  it  unique. 

These  four  direct  memory  access  (DMA)  communication  channels  act  like  small  I/O  computers 
supporting  serial  data  rates  of  up  to  20  Megabits/second.  Because  inter-transputer  communication 
occurs  via  these  DMA  "links"  this  task  does  not  require  the  use  of  the  main  processing  unit.  The 
transputer  was  the  first  microprocessor  to  move  the  floating  point  unit  onto  the  same  chip  as  the 
integer  arithmetic  unit.  This  architecture  allows  the  concurrent  execution  of  integer  operations  with 
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floating  point  operations  which  makes  the  unit  perfoim  much  like  an  array  processor.  The  transputer 
can  perform  scientific  calculations  at  three  to  four  times  that  of  a  Digital  Equipment  Corporations 
Virtual  Address  extension  (VAX)  model  11/780.  The  extreme  processing  power  and  the  inter¬ 
transputer  communications  make  possible  the  construction  of  low  cost  parallel  processor  systems 
that  are  well  suited  for  solving  Kalman  filter  algorithms.  With  these  advancements  in  processor 
technology,  design  of  a  proof  of  principle  prototype  was  initiated. 

2.1  Proof  of  principle  prototype 

Rapidly  evolving  transputer  technology  provided  the  opportunity  to  use  these  devices  for 
computationally  intensive  tasks,  which  previously  required  the  use  of  mainframe  computers.  The 
development  of  a  "proof  of  principle  prototype"  was  initiated  to  show  that  low  cost  red-time  TSPI 
Data  Processors  are  feasible.  The  system  was  to  process  real-time  streams  of  flight  test  data  from 
multiple  radars  and  provide  the  real-time  Best  Estimate  of  Trajectory  (BET)  for  display  and  analysis. 

The  Kalman  filter  portion  of  the  TSPI  Data  Processor  utilized  the  Multi-Station  Solution  (MSS) 
program  that  was  used  at  Edwards  Air  Force  base.  The  MSS  program,  coded  in  FORTRAN,  is  an 
efficient  optimal  estimation  formulation  known  as  the  Square  Root  Information  Hlter  (SRIF). 
Originally  developed  on  a  VAX,  much  of  the  MSS  code  was  used  without  change,  but  additions 
were  made  to  suppon  the  multiprocessor  approach  and  the  r«al-time,  raw  data  characteristics.  The 
goals  of  the  prototype  system  involved  porting  the  large  MSS  FORTRAN  code  to  the  transputer, 
interfacing  the  TSPI  processor  to  a  real-time  data  stream  and  implementing  the  system  using  multiple 
transputers. 

2.1.1  Prototype  Hardware 

The  prototype  TSPI  Data  Processor  system  is  shown  in  Figure  2-2.  The  transputer  based  boards 
were  hosted  on  a  compatible  Personal  Computer  Advanced  Technology  series  (PC- AT)  system  that 
used  a  disk  system  to  store  the  real-time  program  for  downloading  to  the  transputers.  The  PC-AT 
was  also  used  to  display  real-time  processing  statistics.  The  first  board  was  an  interface  card  used  to 
bidirectionally  conven  RS-232  to/firom  the  transputer  link  format,  which  serves  as  the  interface  to 
the  VAX.  The  use  of  the  RS-232  served  two  functions:  it  minimized  the  modifications  to  the  Eglin 
AFB  Central  Control  Facility  (CCF)  system  necessary  for  integration  and  demonstration;  and  the 
nature  of  the  RS-232  standard  demonstrated  the  general  interface  for  other  machines  and 
communication  systems.  The  fact  that  the  CCF  VAX  hardware  restricted  the  data  transfer  rate  to 
19.2  Kilo  baud  was  a  major  disadvantage  to  this  approach.  The  data  transfer  time  at  this  rate  would 
be  0. 1  seconds  even  with  two  separate  input  lines  and  one  output  line. 

The  RS-232  interface  card  made  by  Computer  System  Architects  (CSA)  contains  an  INMOS 
T414  (non-floating-point  transputer)  connected  to  four  serial  interface  chips.  This  design  suppons 
several  modes  for  data  transfer.  This  provided  sufficient  data  transfer  and  increased  flexibility  for 
status  and  control. 
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External  Chasis  PC-AT  Host 

Figure  2-2.  Hardware  /  Software  Structure  for  Prototype  System 


The  other  two  boards,  also  made  by  CSA,  are  identical  and  contain  an  INMOS  T800  floating 
point  transputer  with  1  Megabyte  of  high  speed  memory.  The  transputer  cards  have  significandy 
more  capability  than  required,  but  each  performs  an  important  function  for  the  opdmal  position 
estimate.  The  first  transputer  card  is  used  for  Hlter  Control,  Data  conversions  and  Buffering.  The 
next  transputer  card  is  used  to  perform  the  data  integration  and  evaluation  using  the  SRIF  algorithm, 
and  data  format  for  real-time  output. 

2.1.2  Prototype  Software 

The  real-time  Software  utilizes  multiple  tasks,  concuirently  running  on  two  transputers.  The  first 
transputer  is  running  three  tasks  and  the  second  transputer  is  running  two.  The  description  of  these 
modules  is  described  below. 

2.1.2.1  Filter  Controller 

The  filter  controller  is  the  root  of  the  system  process.  It  is  the  only  component  that  can 
communicate  with  the  PC-AT  host  disk  and  video  display.  At  startup  the  controller  reads  and 
distributes  information  from  the  disk  that  is  used  by  other  tasks.  This  data  includes  radar  instrument 
locations,  measurement  noise  estimates,  weather  information,  pre-mission  calibration  corrections, 
and  input/output  parameters.  Determining  the  source  and  format  of  input  and  output  data  is  an 
important  task  for  the  filter  controller.  The  flexibility  of  being  able  to  change  input  and  output 
options  became  very  useful  during  system  testing. 


The  filter  controller  performs  several  important  run-time  functions  such  as  determining  when  to 
call  the  filter  process.  Each  0.1  second  interval  is  seen  as  a  frame  of  data  and  all  data  in  the  current 
fi^ae  is  held  by  the  controller  until  the  first  data  point  of  the  next  frame.  Although  this  approach 
adds  latency  it  is  a  simple  means  of  synchronizing  the  incoming  data.  The  controller  also  checks  for 
data  dropouts  and  invokes  the  filter  to  provide  an  updated  estimate  even  if  there  is  no  new  data.  The 
controller  also  uses  data  from  the  Filter  task  and  provides  auto-tuning  of  filter  parameters  to  prevent 
solution  divergence. 

The  prototype  utilized  binary  format  real-time  radar  data  as  inputs,  which  were  translated  into 
engineering  units  by  the  filter  controller.  The  controller  applies  calibration  and  refraction  corrections 
to  the  real-time  data.  This  is  accomplished  by  using  pre-mission  angle  and  range  calibration  data, 
along  with  atmospheric  weather  data. 

2.1.2.2  Real'Time  Buffering 

The  buffering  tasks  support  the  input  of  real-time  data  via  the  two  serial  lines.  The  two  identical 
tasks  monitor  each  of  the  serial  lines  and  buffer  the  incoming  data.  The  rejection  of  incorrect  data  is 
accomplished  by  the  buffering  task  checking  the  incoming  data  for  sync  words  and  their  positions. 
This  buffering  was  required  because  of  the  limited  buffering  capacity  of  the  serial  interface  card. 

2.1.23  Filter 

The  Filter  task  is  an  extended  square  root  information  filter  (SRIF)  that  generates  optimal 
estimates  and  error  covariances  fiom  TSPI  measurement  data.  At  start-up,  initialization  messages 
are  sent  to  the  filter  task  via  the  physical  link  connecting  the  two  processors.  These  messages  come 
from  the  Hlter  Controller  and  describe  the  instruments  and  the  type  of  processing  to  be  performed. 
The  Filter  task  also  provides  the  transmission  of  data  messages  on  each  call  to  the  Hlter.  With  a 
fixed  time  interval  in  measurement  data  of  0. 1  seconds,  1000  messages  were  required  to  be  sent  over 
the  link.  The  architecture  used  makes  it  more  efficient  to  send  small  messages  individually  rather 
than  use  a  lot  of  time  packing  and  unpacking  large  messages.  The  Filter  task  was  also  responsible 
for  passing  its  results  to  the  Real-Time  Output  task. 

2.13.4  Real-Time  Output 

The  Real-Time  Output  task  extracts  the  desired  real-time  output  data  from  the  Filter  task  and 
formats  it  for  serial  output.  This  is  accomplished  by  formatting  the  data  into  a  record  structure  that 
contains  position,  velocity,  uncertainty,  and  filter  status.  This  task  also  converts  the  transputer 
floating  point  numbers  (IEEE  Format)  into  the  VAX  format.  The  data  is  then  sent  to  the  serial 
interface  via  a  transputer  link  connecting  the  two  boards. 

2.13  Prototype  Performance 

The  prototype  TDP  was  successfully  interfaced  and  demonstrated  at  the  Eglin  Air  Force  Base 
CCF.  The  TDP  provided  real-time  filtered  output  from  five  streams  of  10  Hz  radar  data  and  was 
displayed  on  mission  consoles  for  accuracy  evaluation.  Comparisons  were  made  between  the  off-line 
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MSS  filter  and  the  TDP  and  the  results  showed  no  degradation  of  track  acci^acy  by  using  the 
transputers. 

System  loading  and  data  latency  were  also  concerns  to  be  investigated.  The  transputer  loading 
was  evaluated  by  off-line  timing  using  embedded  rimers  in  the  code.  The  Filter  and  Output 
transputer  used  about  50%  of  the  available  processor  rime.  The  Control  and  Buffering  transputer 
used  about  70%  of  the  available  cycles  when  refraction  corrections  were  calculated,  and  50%  when 
these  calciriarions  were  turned  off. 

The  latency  was  measured  by  comparing  the  rime  tag  of  the  solution  to  the  time  the  data  arrived 
at  the  source  (VAX)  computer.  This  resulted  in  a  measurement  of  latency  of  0.3  seconds  and  Table 
2-1  below  shows  the  possible  causes  of  this  latency.  (Ref  2.) 


VAX  TO  TRANSPUTER 

REPORT  TRANSFER  TIME 

0.075 

DATA  VERMCATION 

0.025 

REPORT  CONTROLLER  DELAY 

0.05 

CALIBRATION/REFRACTION 

CALCULATION 

0.025 

SRIF 

0.05 

TRANSPUTER  TO  VAX 

REPORT  TRANSFER 

0.025 

VAX  MULTIPROCESSING 

0.025  (est) 

Table  2-1.  Contribution  to  TDP  System  Latency  (Times  in  Seconds) 

The  TDP  demonstrated  that  high-performance,  real-time  TSPI  data  processors  can  be  built  from 
transputers  at  extremely  low  costs.  This  success  lead  to  the  development  of  a  higher  performance 
Breadboard  TDP  system  capable  of  supporting  the  integration  of  Global  Positioning  System  (GPS), 
Radar,  Multilaterarion  and  processed  Theodolite  data. 

2.2  Breadboard  TDP 

The  development  of  the  Breadboard  TDP  was  initiated  to  bring  the  program  one  step  closer  to  a 
production  Data  Processor  for  DoD  Test  ranges.  The  Breadboard  TDP  expanded  the  prototype  to 
integrate  data  from  multiple  range  sensors.  These  sensors  included:  GPS,  Multilaterarion  systems, 
such  as  the  Gulf  Range  Drone  Control  Upgrade  System  (GRDCUS)  used  at  Eglin  and  future  real¬ 
time  theodolites.  The  breadboard  also  utilized  multiple  transputers  and  all  software  is  coded  in  Ada 
for  added  maintainability.  The  breadboard  TDP  included  designs  to  demonstrate  its  utility  under 
actual  flight  test  conditions. 
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2^.1  Breadboard  TDP  Hardware 


The  breadboard  TDP  is  a  single  PC- AT  (16  bit  IBM  compatible)  I/O  card  with  INMOS 
TRAnsputer  Module  (TRAM)  components.  The  card  is  capable  of  accepting  20  TRAMS  which 
allows  the  TDP  to  be  constructed  on  a  single  board.  The  breadboard  TDP  consists  of  five  TRAMS 
identified  as  the  Serial,  Front-End,  Root,  Rlter  Core  and  the  Givens  B.  The  Serial  TRAM  is  used  to 
convert  the  transputer  communication  signals  to  RS-232  compatible  signals.  The  other  four  TRAMs 
contain  the  latest  INMOS  25  MHz  T800  transputers  and  execute  the  algorithms  that  are  functionally 
described  in  the  next  section.  Rgure  2-3  shows  the  interconnections  between  each  module.  The 
TDP  is  hosted  on  a  PC  compatible  INTEL  386  computer  (386  PC)  that  is  used  to  download  the 
code  to  the  transputers  and  display  filter  statistics  during  operations. 


PC  Bus 

(Disk  and  Video  Monitor) 


External  — ► 
Interfaces— 


Figure  2-3.  TRAM  functional  connections 

The  TDP  demonstration  was  designed  not  only  to  show  the  applicability  of  real-time  TSPI  data, 
but  show  the  validity  and  accuracy  of  the  output  data  in  real-time.  This  was  accomplished  by 
providing  the  real-time  TDP  solution  to  a  remote  site  for  automatically  pointing  a  video  camera  at  an 
aircraft  during  an  actual  flight  test  mission.  The  computer  at  the  remote  site  (a  386  PC  slaving 
computer)  was  responsible  for  converting  the  TDP  solution  and  generating  servo  commands  to  point 
the  video  camera  tracking  mount 

2Jt.2  Breadboard  TDP  Software 

Because  transputer  software  development  tools  for  Ada  were  limited,  most  of  the  development 
was  conducted  on  a  386  PC.  The  nature  of  the  Ada  language  permitted  the  emulation  of  the  multiple 
processors  by  the  use  of  separate  Ada  tasks.  This  approach  provided  a  means  to  debug  major 
software  problems  and  check  the  overall  program  logic.  The  testing  of  the  inter-processor  timings 
task  tuning  and  serial  I/O  could  not  be  conducted  until  the  code  was  ported  to  the  transputers.  Once 
this  was  accomplished  the  Front-End  module  and  the  inter-transputer  communications  could  be 
tested. 
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222.1  Front-End  TRAM 


The  Front-end  TRAM  hosts  the  module  that  is  used  to  buffer  the  data  from  the  Serial  TRAM  and 
performs  refraction  corrections,  sensor  coordinate  and  engineering  unit  conversions.  This  module 
must  respond  to  incoming  data  with  low  latency  to  avoid  loss  of  data  from  the  CCF  system  since 
flow  control  is  not  used  in  the  transfer. 

2.2.22  Root  TRAM 

The  Root  TRAM  contains  the  module  that  performs  many  of  the  statistical  functions  for  the 
filter.  The  Root  TRAM  also  supports  disk  and  video  I/O  for  initialization  and  system  diagnosis. 
This  module  calculates  filter  residual  Sigmas,  the  time  propagation  of  state  estimates,  state  Sigmas 
and  combines  the  GPS  XYZ  solution  with  the  filter  estimate.  The  health  of  the  filter  can  be 
monitored  by  the  statistical  data  that  is  periodically  reported  through  the  PC  video. 

2223  Filter  Core  TRAM 

The  Filter  Core  TRAM  performs  the  large  matrix  operations  for  each  filter  cycle  that  are 
computationally  intensive.  These  operations  convert  large  matrices  to  an  upper  triangular  form  using 
the  Givens  formulation.  With  modifications  to  the  algorithms  for  parallelization  the  operation  is 
performed  on  two  processors.  This  allows  the  transformations  to  be  performed  extremely  quickly 
and  is  an  essential  part  of  the  SRIF  in  the  TDP. 

2.22.4  Givens  B  TRAM 

The  Givens  B  TRAM  performs  the  second  half  of  the  Givens  transformation  as  mentioned  above. 
2.23  Breadboard  TDP  Performance 

The  breadboard  TDP  utilized  a  SRIF  implementation,  like  that  used  in  the  prototype,  and  is  very 
similar  to  the  Advanced  Range  Data  Systern  (ARDS)  filter  used  by  Edwards  AFB.  This  provided  a 
means  of  testing  the  TDP  for  correct  implementation  of  the  algorithm  by  comparing  results  from  the 
ARDS  system.  Analysis  showed  that  all  aspects  (including  Sigmas  and  error  states)  of  the  filter 
were  correctly  implemented. 

The  TDP  system  throughput  was  tested  off-line  using  simulated  data.  Table  2-2  describes  the 
results.  The  number  of  error  states  (other  Biases  estimated  by  the  filter)  used  to  calculate  the 
optimal  solution  has  a  direct  impact  on  the  system  throughput.  Improvement  of  the  system 
throughput  may  be  desired  for  certain  applications.  The  hardware  implementation  for  this  algorithm 
was  optimum.  Some  code  optimization  can  be  implemented  but  further  performance  increase  will 
result  from  the  use  of  higher  performance  processors  and  more  mature  compilers.  (Ref  3.) 
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Sensors 

Error  States 

Throughput  rate 

Three  Radars 

4  GRDCTJS  Stations 
GPSXYZ 

9  Kinematic  States 

No  Error  States 

12  Hz 

Three  Radars 

4  GRDCUS  Stations 
GPSXYZ 

9  Kinematic  States 

10  Error  States 

5  Hz 

Three  Radars 

4  GRDdUS  Stations 
GPSXYZ 

9  Kinematic  States 

3  Radar  Error  States 

10  Hz 

Two  Radars 

GPS  Method  3 
(raw  pseudo-range) 

9  Kinematic  States 

4  Error  States 

9Hz 

Table  2-2.  TDP  Throughput  results 


The  flight  test  demonstration  used  the  real-time  solution  from  the  TDP  to  automatically  point  a 
remote  tracking  pedestal  with  a  video  camera  mounted  on  it.  The  solution  was  sent  via  a  microwave 
link  to  the  slaving  computer  located  at  a  remote  test  site  (C-10).  This  computer  was  responsible  for 
reading  the  cuirent  range  time,  the  pedestal  position,  converting  the  solution  to  a  local  reference 
frame,  compensating  for  latency  in  the  solution  and  generating  the  error  signal  for  the  mount  servo 
system.  The  slaving  computer  was  a  386  PC  that  used  3  digital  I/O  cards  and  a  modem  to  interface 
to  the  remote  site  data  systems.  Figure  2-4  shows  the  TDP  interface  connections  and  the  data  flow 
structure  used  for  the  demonstration.  The  figure  shows  tracking  data  coming  into  CCF  and 
processed  by  the  TDP  where  it  is  then  sent  via  microwave  to  the  tracker  at  site  (C-10). 

This  demonstration  was  very  successful  and  showed  the  TDP  system  providing  significantly 
better  and  smoother  tracking  then  the  existing  Secondary  Data  slaving  system  used  at  Eglin  AFB. 
When  GPS  data  was  used,  the  demonstration  showed  that  the  system  pointed  the  mount  for  both  low 
and  high  dynamic  maneuvers  with  extreme  accuracy  (sometimes  within  3-5  feet).  This  was  possible 
because  of  the  ability  for  GPS  to  provide  accurate  velocity  estimates  and  accurate  data  even  at  low 
altitudes.  A  short  video  tape  of  this  demonstration  was  made  and  is  available  for  viewing. 

23  Fixed'Lag  Smoother 

Optimal  smoothers  have  traditionally  used  fixed  interval  smoothers  operating  in  a  reverse  time 
manner,  starting  at  the  end  of  a  filtered  data  process  and  working  backwards  to  the  beginning.  This 
technique  is  used  where  real-time  highly  accurate  solutions  are  not  needed  and  are  typically 
performed  as  a  post  mission  process.  The  Fixed-Lag  Smoother  works  in  parallel  with  the  real-time 
optimal  filter  and  uses  filter  information  to  produce  state  estimates  that  lag  the  real-time  estimates 
a  small  fixed  interval. 
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Figure  2-4.  Breadboard  interface  connections 


23.1  Fixed-Lag  Smoother  Software 

The  algorithm  essentially  buffers  data  from  the  Filter  over  a  small  delta  time  period  and  then  runs 
the  smoother  formulation  backwards  to  the  previous  delta  time  interval.  This  process  is  continuous 
and  smoothed,  but  slighdy  delayed  estimates  are  provided  along  with  the  real-time  output.  All 
algorithms  were  coded  in  Ada  and  tested  on  a  386  PC  but  were  not  integrated  into  multiple 
transputers.  Loading  analysis  indicated  that  the  Fixed-Lag  Smoother  could  be  implemented  using 
one  additional  transputer. 

232  Fixed-Lag  Smoother  Performance 

The  accuracy  evaluation  required  the  use  of  synthetic  radar  data  and  synthetic  GPS  pseudo-range 
and  delta  pseudo-range  data.  TTiis  provided  a  "truth"  data  set  to  compare  the  filtered  results  to.  The 
synthetic  data  was  corrupted  with  characteristic  error  signals  for  each  range  sensor.  The  first  test 
used  radar  data  at  5  Hz  with  a  fixed  lag  of  2  seconds.  The  results  compared  the  filter  errors  to  the 
smoother  errors.  The  smoother  reduced  the  Root  Mean  Square  (RMS)  position  error  by  30  percent 
and  the  velocity  errors  by  70  percent.  The  next  test  used  GPS  data  at  5  Hz  with  a  2  second  lag.  The 
position  errors  were  reduced  by  30  percent,  the  velocity  errors  more  than  80  percent  and 
acceleration  errors  by  over  90  percent.  (Ref  4.) 

The  Fixed-Lag  Smoother  demonstrated  significant  accuracy  improvements  relative  to  the  real 
time  filter  with  fixed  lags  of  0.5  to  2.0  seconds  that  are  reasonable  for  most  real-time  needs.  This 
provides  a  solution  comparable  in  accuracy  to  post  flight  smoothing  processes  that  typically  required 
hours  or  even  days  of  turnaround  time.  This  work  will  continue  during  the  Brassboard  development 

2.4  Brassboard  TDP 

The  demonstrations  in  the  previous  efforts  showed  that  low  cost  real-time  TSPI  data  processors 
can  be  developed  to  provide  optimal  estimates  to  be  used  for  slaving  and  mission  analysis.  This 
substantiated  the  need  to  develop  a  fieldable  system  to  be  used  by  all  DoD  Test  ranges.  The  TDP 
system  will  improve  the  reliability  and  maintainability  of  DoD  test  range  tracking  systems  through  the 
use  of  standardized  and  common  hardware.  The  use  of  common  equipment  required  a  survey  of 
requirements  from  all  applicable  DoD  test  ranges.  The  results  of  these  surveys  are  reflected  in  the 
system  designs. 

2.4.1  Brassboard  System  Designs 

The  TDP  will  use  industry  standard  computer  processors,  communications  interfaces  and 
software  to  provide  accurate  trajectory  estimates  through  the  integration  of  range  sensor  data.  The 
minimum  TDP  will  provide  filtering  for  a  single  track  and  shall  be  expandable  to  allow  filtering  for 
up  to  six  separate  tracks  simultaneously.  When  required,  the  full  TDP  will  support  up  to  three  tracks 
and  three  smoothers  simultaneously.  The  TDP  will  select,  from  an  incoming  data  stream,  the 
appropriate  information  and  route  it  to  proper  processors  providing  the  multiple  TSPI  tracks.  Each 
track  processor  has  the  capability  of  processing  data  from  up  to  10  instruments  and  providing 
estimates  at  rates  of  up  to  60  Hz.  The  configuration,  control  and  monitoring  of  the  TDP  is 


91 


accomplished  using  an  external  Host  Computer  communicating  via  a  well  defmed  control/status 
interface. 

The  TDP  will  support  three  modes  of  operation.  The  first  mode  will  provide  a  low  latency  (less 
than  0.1  seconds),  high  accuracy  trajectory  estimate  to  be  used  in  slaving  of  closed  loop  systems  such 
as  video  tracking  systems.  The  second  mode  will  provide  near-real-time  generation  of  higher 
accuracy  estimates.  These  estimates  can  lag  the  current  time  by  as  much  as  0.5  seconds  and  will  be 
used  for  on-line  analysis  and  display  for  mission  control.  The  third  mode  will  support  smoothing  to 
provide  additional  accuracy  to  the  trajectory  estimate.  The  smoothed  trajectories  will  lag  the  filtered 
outputs  by  several  seconds  and  can  be  used  for  post-flight  mission  review. 

The  TDP  will  use  the  VMEbus  open  system  architecture  well  accepted  by  industry  and  the 
military.  The  use  of  this  architecture  provides  the  capability  for  end  users  to  purchase  low  cost,  non¬ 
proprietary,  standard  off-the-shelf  modules  to  assemble  and  construct  a  TOP  system.  The  TDP 
system  architecture  is  shown  in  figure  2-5.  The  TOP  is  partitioned  into  two  major  sections  known  as 
the  Range  Interface  and  the  Track  Generator.  The  communications  between  these  two  sections  will 
utilize  the  high  performance  VME  data  bus.  The  primary  communications  will  be  data  flow,  but  the 
bus  will  also  serve  as  a  means  for  the  Range  Interface  to  control  the  processors  in  the  track 
generator. 

The  Range  Interface  is  responsible  for  input/output  and  control  functions  of  the  TOP.  These 
functions  include:  receiving  the  raw  data,  receiving  and  processing  control  commands,  monitoring 
the  track  generator  output,  routing  data  to  the  appropriate  compute  modules  and  all  data 
conversions.  The  Range  Interface  will  require  at  least  one  general  purpose  processor  and  one  or 
more  intelligent  I/O  cards.  The  Range  Interface  will  also  assume  the  role  of  the  bus  master  for  the 
VME  system  and  places  the  VME  chassis  and  bus  within  its  domain.  The  addition  of  non-TOP 
hardware  will  be  supported  by  the  Range  Interface  with  restrictions  identified  for  address  and 
interrupts.  Some  of  the  interfaces  supported  include:  Host  interface  (status,  command,  and  setup 
information).  Track  solution  interface.  Range  Time  interface  and  the  sensor  interface.  The  sensor 
interface  is  where  the  measurement  data  is  made  available  for  the  TOP.  The  structure  of  this  data 
has  been  organized  to  provide  a  generic  description  that  can  apply  to  many  different  facilities.  These 
generic  descriptions  are  provided  in  table  2-3. 

The  Track  Generator  modules  perform  the  computationally  intensive  Kalman  filtering  of  sensor 
data.  The  Track  Generator  accepts  data  and  commands  from  the  Range  Interface  and  provides  a 
filtered  or  smoothed  output.  Each  module  contains  two  high-performance  microprocessors  and  is 
capable  of  executing  either  one  filter  or  one  smoother.  It  should  be  noted  when  configured  as  a 
smoother  an  additional  module  must  be  configured  as  a  filter  to  provide  the  smoother  the  appropriate 
data. 
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Host  Computer 

Figure  2-5.  Brassboard  TOP  System  Architecture 


TDP  DATA 
TYPE 

CANDIDATE  SENSORS 

DATA  DESCRIPTIONS 

Ground  based 
tracker 

Conventional  Radar,  Laser  Radar, 
Doppler  Velocimeter  Radar,  MOTR 
Theodolite,  Ranger 

Azimuth,  Elevation,  Range,  Range 

Rate.  Used  as  filter  measurements. 

Altimeter 

Baro  Altimeter 

Altitude  above  Spheroid. 

Used  as  filter  measurements. 

Cartesian 

Position 

GPS  XYZ  Position  Solution 

Other  XYZ  Position  Solutions 

XYZ  ECEF  Position  or  ENU  Position 
(Fixed-Site  Local  Tangent  Plane). 

Used  as  filter  measurements. 

Velocity 

INS 

GPS  XYZ  Velocity  Solution 

Other  XYZ  Velocity  Solutions 

XYZ  ECEF  Velocity  or  ENU  Velocity 
(Fixed-Site  Local  Tangent  Plane)  or 
Velocity  (Vehicle  Local  Level).  Used 
as  filter  measurements. 

Acceleration 

INS 

Other  Acceleration  Source 

Acceleration  (Vehicle  Local  Level), 

Used  to  improve  the  INS  Velocity 
model.  (Optional) 

Attitude 

INS 

Other  Attitude  Source 

Heading,  Pitch,  Roll.  Used  to  improve 
track-point  corrections  (Optional) 

GPS  Raw 
Measurements 

HDIS,  Joint  Program  Office  User 
Equipment.  Other  GPS  receivers 

Pseudo-range,  Delta  Pseudo-range. 

Used  as  filter  measurements. 

GPS  Satellite 
Constellation 

GPS  Receiver 

GPS  Reference  Receiver 

Various  Ephemeris  quantities  for 
determining  satellite  locations.  Used 
to  support  processing  of  raw  GPS. 

GPS  Reference 
Receiver 

Range  Applications  JPO  GPS 
Reference  Receiver.  Other  GPS 
Reference  Receivers. 

Differential  corrections.  Tropospheric 
correction.  Ionospheric  delay,  rate  of 
change  for  iono  delay.  Used  for 
differential  corrections  of  raw  GPS. 

Model  Aiding 
Event 

Bomb  Tone,  Telemetry,  Other  Event 
Signal 

Event  Signal.  Used  to  transition  filter 
from  dead  reckoner  to  model  aided. 

Model  Aiding 
Reference 

Off-Line  Simulation 

Position,  Velocity  and  acceleration 
time  history.  Stored  at  setup. 

Table  2-3.  Generic  data  descriptions  (Ref  5.) 


The  algorithms  from  the  previous  tasks  will  be  adapted  to  increase  and  add  new  requirements 
from  various  DoD  Test  ranges.  The  original  strategy  for  the  brassboard  designs  would  have  used  the 
next  generation  transputer,  but  INMOS  will  not  have  it  available  in  time  for  our  development.  The 
present  approach  will  utilize  the  latest  Reduced  Instruction  Set  Computing  (RISC)  microprocessors 
that  have  been  benchmarked  at  10  to  12  times  faster  than  the  T800  Transputer  used  in  the 
breadboard.  The  importance  of  these  high  performance  processors  becomes  evident  when  the  TDP 
is  providing  very  low  latency  real-time  estimates  for  systems  like  those  discussed  in  section  3. 
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3.  TDP  APPLICATIONS 


The  use  of  real-time  optimal  TSPI  estimates  can  provide  many  benefits  for  flight  tests  at  DoD 
ranges.  Some  applications  that  are  well  suited  for  the  TDP  are  addressed  in  the  following  sections. 

3.1  Conventional  Slaving  Systems 

Current  Radar  Simulation  systems  require  high  accuracy,  low  latency  TSPI  solutions  to 
accurately  point  radar  emitters  for  systems  evaluation.  As  demonstrated  during  the  breadboard  flight 
testing  the  TDP  is  quite  capable  of  providing  solid,  accurate  and  low  latency  solutions  to  be  used  for 
pointing  these  and  other  types  of  systems. 

Other  applications  require  the  illumination  of  a  target  for  higher  accuracy  tracking  systems  to 
acquire.  An  example  of  this  could  be  an  infrared  optical  tracking  system  using  the  TDP  to  point  an 
infrared  emitter  allowing  the  tracker  to  acquire  the  target  or  eliminating  background  interference 
detecting  the  illuminated  target 

An  obvious  application  of  the  TDP's  real-time  solution  is  to  provide  a  best  estimate  of  trajectory 
to  be  used  in  pointing  video  theodolites.  The  improved  accuracy  of  a  TDP  solution  relative  to  a  raw 
or  single  sensor  system  will  allow  tracking  with  longer  focal  lengths,  and  hence  greater  effective 
resolution,  of  targets.  The  TDP  breadboard  system  was  used  quite  successfully  in  this  mode  during 
1991  demonstrations  at  Eglin  AFB. 

3.2  Real-time  Integration  of  Video  Tracker  Data 

The  TDP  has  been  developed  to  allow  the  processing  of  both  raw  and  filtered  data.  This  allows 
the  solution  provided  by  a  centralized  TDP  to  be  used  as  an  input  to  a  TDP  processing  video  tracker 
data.  The  pedestal  and  offset  data  would  be  sent  through  the  local  TDP  operating  in  a  fixed-lag 
smoother  mode  to  provide  high  accuracy,  near-real-time  trajectory  solutions.  These  solutions  could 
be  used  locally  or  sent  back  to  the  centralized  location  for  real-time  mission  analysis. 

33  Closed  Loop  Integration  of  Video  Tracker  Data 

A  very  useful  TDP  application  is  the  incorporation  of  the  TDP  in  a  closed  loop  mode  with  optical 
trackers.  This  is  shown  in  Hgure  3-1.  Here  the  high  accuracy  solution  that  incorporates  all  of  the 
video  tracker  data  into  the  solution  is  fed  back  to  each  mount.  The  major  advantage  of  this  approach 
is  to  provide  automatic  correction  when  a  single  mount  looses  track  (e.g.,  the  video  tracker  locks 
onto  the  wrong  object).  The  filter  will  reject  the  data  from  the  mount  that  has  lost  track  because  it 
will  be  inconsistent  with  the  other  sensors.  However,  all  mounts  will  continue  to  receive  correct 
pointing  commands  (including  the  incorrect  mount)  based  on  the  incorporation  of  the  data  from  aU 
the  on-track  video  systems.  This  provides  improved  robusmess  and  should  significantly  enhance  the 
effectiveness  of  the  individual  pedestal/tracker. 
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TDP(s) 


Figure  3-1 .  Closed  Loop  Tracker  data  integration 


3.4  Model  Aiding 

Objects  having  extremely  rapid  changes  in  acceleration  (jerk)  have  typically  been  extremely 
problematic  for  video  and  other  types  of  tracking  systems.  The  TDP  can  overcome  these  problems 
through  its  support  of  a  "model  aided"  filtering  mode.  In  this  mode  an  external  event  (e.g.,  telemetry 
signal)  is  used  to  trigger  the  use  of  an  apriori  velocity  profile  in  the  filter.  The  filter  uses  this  for  state 
propagation  and  therefore  only  has  to  track  the  variation  from  the  expected  trajectory.  This 
improves  the  ability  to  follow  the  target,  and  improves  the  filtering  output  since  the  filter  gain,  and  Q 
can  be  kept  low.  (Ref  6.) 

3.5  Improved  Real-Time  Data  Accuracy/Reliability 

With  the  rapid  advancements  in  weapon  systems  development,  test  range  requirements  have 
become  increasingly  complex.  DoD  test  ranges  are  finding  that  these  systems  require  larger  test 
areas  for  systems  evaluation.  The  TDP  can  provide  improved  real-time  accuracy/reliability  thereby 
reducing  the  safety  footprint  requirement  and  allowing  efficient  testing  of  longer  range  munitions. 

3.6  Current  Planned  Applications 

The  TDP  project  is  actively  involved  in  several  video  related  applications.  At  Eglin  the  TDP  will 
be  demonstrated  at  two  facilities.  In  the  Central  Control  Facility,  the  TDP  will  be  used  provide 
mission  managers  with  BET  solutions  in  real-time.  This  solution  will  also  be  made  available  for 
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other  range  users.  A  second  facility,  a  3  station  video  tracker  range,  will  use  the  TDP  to  support 
slaving,  real-time  video  integration,  and  closed  loop  tracking.  The  TDP  at  that  site  will  also  include 
a  processor  to  calculate  and  output  error  signals  to  the  pedestal  servos.  This  computer  will  use 
shared  VME  bus  memory  to  minimize  system  latency.  Figure  3-2  illustrates  this  system. 


S  =  Servo  at  C-7 
M  =  Remote  Mount 
TVT  =  Television  Tracker 


Figure  3-2.  Remote  Site  TDP  system 


A  similar  project  at  White  Sands  is  initially  limited  to  processing  a  large  number  of  radar  tracks 
and  providing  pointing  commands  to  documentation  cameras  It  is  expected  that  this  will  be 
upgraded  to  closed-loop  control  of  the  video  system. 

Finally,  there  are  tentative  plans  for  the  use  of  the  TDP  in  a  mobile  theodolite  (KTM  mount) 
system.  In  this  Edwards  Air  Force  Base  system,  the  TDP  would  provide  both  real-time 
coordination  of  the  mounts  and  quick-look  TSPI  results. 


97 


4.  CONCLUSION 


The  TSPI  Data  Processor  breadboard,  developed  by  Wright  Laboratory,  demonstrated  that  low 
cost  processors  can  be  used  to  process  and  integrate  range  test  data  from  multiple  range  sources  and 
compute  optimal  real-time  TSPI  solutions  for  test  aircraft  and  weapons.  The  current  effort  will 
develop  standardized,  fault  tolerant,  and  ruggedized  TDP  systems  for  use  at  DoD  test  ranges. 

Real-Time  integration  of  TSPI  data  can  provide  many  benefits.  Use  of  the  TSPI  Data  Processor 
can  significantly  increase  the  Services'  capability  to  evaluate  new  aircraft  and  weapon  systems.  The 
current  procedure  for  flight  test  missions  is  to  process  TSPI  data  after  the  mission  is  completed.  If 
the  test  engineer  determines  that  the  data  was  not  adequate,  then  all  test  resources  are  rescheduled 
and  another  mission  is  flown.  The  TSPI  Data  Processor  can  provide  accurate  data  that  would  allow 
the  test  engineer  to  assess  the  mission  while  it  is  in  progress.  This  capability,  when  coupled  with 
real-time  test  item  data,  could  reduce  the  number  of  flight  test  missions  by  a  factor  of  2  or  more,  with 
like  reductions  in  test  costs.  For  the  first  time,  it  allows  presently  installed  range  instmmentation  to 
be  integrated  with,  and  optimally  benefit  from,  the  much  improved  performance  that  real-time  GPS 
data  can  provide. 
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PHASE  III  -  BRASSBOARD  MULTI-TRACK  TSPI  DATA  PROCESSOR 


TDP  BRASSBOARD  GOALS 
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DEVELOP  ALL  CODE  IN  ADA 
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•  Larger  latency  (dependent  on  smoother  lag) 

•  Near-Real-Time  display/analysis  applications 

•  Fixed-Lag  Smooth  based  on  filter  results 
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•  TDP  UTILIZES  FIXED  INTERVAL  WITH  SHORT  INTERVALS 
RECURSIVE  TECHNIQUES  WERE  NUMERICALLY  UNSTABLE. 


FIXED  INTERVAL  SMOOTHING 
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FIXED  LAG  SMOOTHER 
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SMOOTHER 

SOLUTION 


Figure  3-2.  Comparison  of  Real-Time  Filter 
and  Fixed-Lag  Smoother 
(Position  Accuracy). 
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RLTER:  ESTHIIATE  MINUS  TRUTH 
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Comparison  of  Real-Time  Filter  and 
Fixed-Lag  Smoother  (Velocity  Accuracy) 
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Pseudorange  and  delta  pseudorange  measurements  at  5  Hz. 
Fixed  Lag  -  2  sec  (10  measurements). 
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Figure  3-4.  Acceleration  Estimation  with  Fixed-Lag  Smoother  is 

Particularly  Impressive 
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FIXED  LAG  SMOOTHER 
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CAN  BE  DISPLAYED  FOR  NEAR-REAL  TIME  ANALYSIS 
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TARGET  DYNAMICS 


TSPI  DATA  PROCESSOR  MODEL  AIDING 


115 


TSPI  DATA  PROCESSOR  MODEL  AIDING 
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Time  Space  Position  information  Data  Processor 
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INTRODUCTION 

It  has  been  quite  interesting  to  observe  the  cyclic  waxing  and 
waning  of  Test  and  Evaluation  reporting  requirements  over 
the  last  several  years.  The  changing  geopolitical,  fiscal, 
technological  and  chronological  facets  of  the  Test  and 
Evaluation  (T  &  E)  arena  have  driven  these  requirements 
through  a  nearly  circular  course  of  development,  decline,  and 
redevelopment,  as  each  has  evolved  to  exert  varying 
influence  upon  the  overall  reporting  process.  As  data  scientists  we  have  struggled  to  track 
and  define  these  changing  requirements  and  implement  state-of-the-art  hardware  and 
software  systems  designed  to  meet  current  reporting  needs  and  provide  for  those  in  the 
foreseeable  future.  Of  particular  interest  here  will  be  the  details  of  these  aforementioned 
elements  as  they  pertain  to  publication  of  Near-Real-Time  data  reports  (NRTRs),  often 
referred  to  as  quick-look  reports;  the  evolution  of  requirements  for  these  kinds  of  data 
representations  at  White  Sands  Missile  Range,  NM  (WSMR);  the  concepts  and 
methodologies  employed  by  data  scientists  at  WSMR  to  meet  current  requisites  in  this 
area;  and  the  plans,  being  made  at  this  very  moment,  to  meet  the  projected  near-real-time 
reporting  needs  of  the  Army  well  into  the  next  century. 


THE  RISE  OF  ‘^OUTCK-LOOK*^ 

A  decade  and  a  half  ago,  renewed  interest  was  building  rapidly  in  the  idea  of  generating 
“qmck-look”  representations  of  data  being  collected  in  real-time.  Test  data  collection  and 
reduction  requirements  had  become  immense  with  huge  volumes  of  data  being  generated 
upon  which  extremely  complex  iterative  processes  were  being  performed  to  derive  test 
results.  As  testing  costs  escalated  more  measurements  were  being  squeezed  out  of  fewer 
test  flights,  further  adding  to  data  collection  and  reduction  burdens.  The  most  obvious 
effect  of  these  ever  increasing  test  requirements  was  a  commensurate  increase  in  the  post¬ 
flight  data  reduction  time  period  needed  to  meet  thenti  Test  conductors  could  expect  to 
wait  up  to  30  days  to  receive  reduced  data  reports  from  a  modestly  complex  mission.  To 
provide  interim  data  products  during  this  post-flight  period  many  test  ranges  put  together 
special  quick-look  systems  usually  comprised  of  strip  chart  recorders,  video  hard-copy 
machines,  video  recorders,  data  collection  computer  line  printers,  pen-plotters  and  other 
data  display  system  hardcopy  devices.  These  systems  supplied  the  test  conductor  with 
“raw”  data,  on  paper  and  in  real-time,  that  could  usually  give  some  good  iiutial  indications 
of  the  relative  success  or  failure  of  key  elements  of  a  particular  test.  These  initial  results, 
that  could  be  immediately  reported  up  the  chain  of  command,  were  becoming  increasingly 
important  to  the  political,  admiiustrative  and  budgetary  captains  with  whom  the  futures 
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of  many  projects  were  resting.  Although  definitely  “quick”  these  data  representations 
were  fraught  with  limitations.  They  were  produced  in  as  many  different  formats  and  form 
sizes  as  there  were  machines  to  produce  them,  with  each  data  source  producing  a  distinct 
and  separate  ouqiut  that  was  generally  incompatible  with  those  of  other  sources.  These 
materials  were  invariably  in  forms  that  required  a  good  deal  of  analytical  interpretation 
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BASIC  REQUIREMENTS  FOR  NEW  NRTRs 


Armed  with  observations  of  past  quick-look  systems  and  well  aware  of  the  new  T  &  E 
environment  of  the  90s  (ie.  sell,  sell,  sell)  it  was  rather  simple  to  define  the  basic 
requirements  for  a  viable  NRTR  publishing  system.  The  system  would  have  to  provide 
concise,  mission  specific,  reports  that  combined  the  data  outputs  from  a  wide  array  of 
sources  into  a  single,  cohesive  product  that  was  accurate,  colorful  and  appealing,  and 
available  on  standard  size  forms.  Most  importantly  the  NRTR  would  have  to  be 
publishable  immediately  after  the  completion  of  a  test,  at  little  or  no  extra  cost  to  the  test 
conductor,  and  would  have  to  be  meaningful  to  top  level  administrators  as  well  as 
engineers  and  scientists.  Sounds  like  a  tall  order  -  but  with  a  seemingly  endless  selection 
of  inexpensive,  off-the-shelf  desktop  publishing  hardware  and  software  to  choose  from, 
ready  access  to  the  vast  data  collection  and  display  resources  at  WSMR,  and  a  motivated 
team  of  engineering  and  scientific  experts,  a  prototype  NRTR  publishing  system  that 
meets  these  basic  requirements  was  implemented  and  put  into  operation  at  WSMR. 
Details  of  the  implementation  of  individual  elements  of  the  system,  as  they  relate  to  the 
fulfillment  of  the  stated  basic  requirements,  will  now  be  examined. 


NRTR  DATA  SOURCES 

It  was  decided  that  the  report  would  be  based  on  three  major  data  sources.  First,  the 
detailed  operational  requirements  documents  (ORs),  classification  guides,  and  expected 
milestone  schedules  of  the  project  for  whom  a  NRTR  was  being  produced  would  be  used. 
Second,  TSPI  data  from  RADARs  and  Telemetry  being  processed  and  displayed  on  the 
Interactive  Graphics  Display  Systems  at  WSMR  would  be  utilized.  These  displays 
provide  position  plots  against  detailed  map  backgrounds.  Instantaneous  Impact  predic¬ 
tions  (nPs),  multi-trace  axis  graphs,  animations  of  three  dimensional  scale  models 
showing  test  vehicle  attitude,  and  digital  representations  of  numeric  data.  The  key  here 
was  the  IGDS  ’  ability  to  provide  hardcopy  of  all  of  these  display  formats  on  8 .5  x  1 1  forms, 
in  real-time.  And  third,  optical  and  video  data  from  field  cameras  transmitted  to  a  central 
collection  point  for  storage  on  video  tape,  in  real-time,  would  be  included.  Emphasis 
would  be  placed  on  maximizing  use  of  color,  recognizable  logos  and  symbology,  graphical 
and  tabular  data  representations,  flowing,  variable  font  and  pitch  text,  and  avoidance  of 
overly  technical  language  or  unintelligible  acronyms.  Every  attempt  would  be  made  to 
create  substantive  reports  that  were  unclassified  to  provide  for  widest  possible  dissemi¬ 
nation,  whilemaintainingthecapabilitytoproduceclassifiedreportsiftheneedarose.  The 

overaU  report  would  be  kept  as  concise  as  possible  with  a  maxinnnTn  length  of  three  printed 
pages. 
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Close  personal  interaction  with  project  engineers  and  test  conductors  while  examining 
project  ORs,  and  expected  mission  milestone  scheduling  was  key  to  incorporating  these 
data  into  an  NRTR.  After  intense  consultation  with  these  personnel,  test  background 
information,  discrete  test  objectives,  mission  requirements,  expected  results,  and  mission 


production  requiring  weeks  of  preparatory  work  long  before  mission  T-time.  It 


yiDEO/OPTTCAL  DATA  COLLECTION 


At  the  same  time  another  member  of  the  NRTR  team  would  be  monitoring  video  and 
optical  transmissions  from  the  field  as  they  were  being  taped  in  the  main  optical  data 
collection  facility  at  WSMR.  A  separate  set  of  tapes,  one  for  each  active  camera,  would 
be  made  expressly  for  NRTR  production.  The  NRTR  team  member  would  be  marking 
particularly  noteworthy  frames  of  optical  data  as  they  occurred.  Typical  examples  of  such 
frames  would  be  at  launch,  intercept,  warhead  event,  or  ground  impact.  As  soon  as  the 
mission  completed,  this  team  member  would  access  those  marked  frames  through  a  high 
quality  video  recorder  and  digitize  them  with  a  video  frame  grabber  attached  to  a  386  PC 
platform.  The  results  of  this  digitizing  process  would  be  standard  EPS  files  of  photo¬ 
quality  images  that  could  be  transferred  to  the  main  NRTR  production  platform  for 
cropping,  sizing  and  image  enhancement  similar  to  that  which  was  applied  to  the  TIE  files 
previously  described. 


NRTR  FINAL  PRODUCTION 

While  team  members  worked  with  the  image  data,  the  NRTR  team  leader  would  be 
preparing  for  final  report  generation  by  inserting  key  wording  describing  the  initial  success 
or  failure  of  the  mission,  along  with  specific  numeric  measurements  or  assessments  and 
prevailing  weather  data,  into  the  NRTR  textual  template.  Then  TEF  files  of  the  IGDS  TSPI 
data  would  be  overlaid  into  awaiting  template  positions.  Borders,  connectmg  lines  and 
text  annotations  would  be  affixed  to  the  Tib  images  to  create  composite  graphics  around 
which  the  text  of  the  template  would  flow.  Finally  the  EPS  optical  images  would  be 
brought  into  their  template  positions  with  appropriate  borders  and  captions  being  applied 
as  needed.  This  final  report  assembly  process  would  be  preformed  using  a  general  purpose 
desk-top  publishing  package  running  on  a  486  PC  platform.  The  final  product  would  then 
be  printed,  in  Postscript  format,  on  a  high  resolution,  full  color  thermal  wax  transfer  printer 
attached  to  the  486  publishing  platform.  At  an  average  of  twelve  minutes  per  page  this 
would  be  the  most  lengthy  single  process  in  the  production  of  the  NRTR.  After  printing 
completed,  the  original  report  pages  would  be  reproduced  on  a  high  quality  color  copier 
as  specified  by  the  project 
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NRTR  PRODTJCTTON  TIME 


The  NRTR  production  time  goal  would  be  two  hours  after  mission  completion.  To 
achieve  this  goal  several  noteworthy  steps  would  be  taken.  Of  course,  as  much  work  as 
was  possible  would  be  done  before  the  mission  ever  started.  The  major  processes  involved 
in  NRTR  production  would  be  done  in  parallel,  on  separate  PC  platforms.  Key  facets  of 
the  NRTR  process,  from  the  initiation  of  IGDS  hardcopies  to  the  production  of  color 
copies  would  be  handled  by  specific  team  members  as  their  sole  responsibilities.  And, 
most  importantly,  the  team  would  practice,  practice,  practice,  going  through  countless  dry- 
runs  where  equipment  and  production  logistics  would  be  exercised  under  actual  time  and 
data  conditions.  Great  attention  would  also  be  given  to  logistical  contingencies.  Each 
production  hardware  system  would  be  provided  with  a  hot  backup;  each  production 
process  team  member  would  be  prepared  to  execute  using  alternate  sources  and  methods; 
a  library  of  representative  photographic  and  graphic  images  was  built  as  an  emergency 
source  in  case  field  video  or  IGDS  hardcopies  could  not  be  collected  for  some  reason. 
These  contingency  plans  would  prove  invaluable  during  the  first  NRTR  production  run. 


MAXIMIZING  NRTR  VALUE 

The  final  goal  was  to  minimize  costs  to  the  customer  for  production  of  NRTRs. 
Ideally,  this  could  be  achieved  by  simply  defraying  the  costs  of  production  within  the 
standard  rates  already  being  charged  for  using  the  WSMR  range  facilities.  The  customer 
would  then  see  no  “extra  charge”  for  a  substantially  useful  new  data  product.  It  seems  as 
though  one  might  be  losing  their  shirt  on  a  deal  like  this,  but  in  fact,  conditions  at  WSMR 
were  perfect  for  the  development  of  this  capability  without  procuring  new  equipment, 
soliciting  outside  expertise  or  hiring  extra  persoimel.  The  basic  hardware  and  software 
systems  used  to  create  NRTRs  had  already  been  purchased  as  part  of  an  upgrade  to  the 
IGDS  display  system,  and  were  being  used  to  document  Government  developed  software, 
and  to  prepare  briefing  and  presentation  materials  (see  figure  1 ).  Many  of  the  methods  and 
practices  employed  in  NRTR  production  were  actually  perfected  while  the  system  was 
being  used  for  this  original  purpose.  A  similar  system,  used  for  graphics  arts  production 
at  the  WSMR  visual  information  department  was  also  already  in  operation.  It  was  a  simple 
matter  to  slightly  reconfigure  and  reasssign  these  systems,  neither  of  which  was  being 
100%  utilized,  to  the  purposes  of  creating  NRTRs.  There  were  several  Government 
personnel  who  were  experts  in  the  operation  of  these  systems,  and  who  were  top  real-time 
programmers  and  analysts  familiar  with  the  WSMR  data  collection  and  display  systems. 
These  individuals  would  make  up  the  NRTR  production  team  and  would  take  on  this 
responsibility  as  a  part  of  their  normal  duties.  Thus,  the  creation  of  a  new  and  substantial 
capability  would  be  facilitated  essentially  without  additional  cost  to  the  Government,  or 
the  customer. 
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DISPLAY  FLOW  DIAGRAM 
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THE  FINAL  PRODUCT 


The  fruition  of  these  concepts,  methods,  processes  and  practices  that  have  just  been 
described  are  the  final  NRTR.  A  reborn  quick-look  report  that  is  packed  with  data  from 
many  sources  and  flush  with  color,  imagery,  photographs  and  icons.  It  was  meant  to  be 
as  “commercial”  as  it  was  scientific;  as  much  a  public  relations  vehicle  as  it  was  a  forum 
for  vital  test  data.  It  is  as  appropriate  on  the  desk  of  an  engineer  as  it  is  as  an  inclusion 
in  the  most  formal  Pentagon  report  The  reports  that  have  been  generated  so  far  came  out 
very  nicely  and  created  quite  a  stir  among  users  and  customers  of  WSMR.  The  reports 
have  been  described  by  many  as  “brochures”  or  “magazines”  -  a  testimony  to  their  quality 
and  appeal.  The  appendices  at  the  end  of  this  document  show  some  examples  of  NRTRs 
that  were  generated  during  the  development  of  the  template  for  the  first  real  NUTR 
customer  -  the  Army  Tactical  Missile  System  (Army  TACMS). 

The  progression  of  overall  concept  development  from  the  first 
template  (appendix  A),  to  the  finished  product  (appendix  C)  is 
quite  evident,  as  is  the  movement  to  greater  information 
density,  succincmess,  and  “openness”.  It  should  be  noted  that 
the  sample  of  appendix  C  is  a  copy  of  the  first  actual  NRTR 
that  was  ever  produced  at  WSMR.  This  NRTR  was  made  on 
14  April,  1992  immediately  following  an  Army  TACMS  full 
production  test  using  exactly  the  methodologies  that  have  just 


been  described.  The  two  hour  production  time  goal  was  actually  exceeded  such  that  there 
was  time  to  go  back  and  make  small  changes  to  the  finished  product  -  a  little  extra  polish 
(recall  that  the  original  plan  called  for  a  “once  through”  approach  to  meet  the  time  line)! 
Several  wonderful  examples  of  Murphy’s  Law  were  experienced,  to  the  extent  that  if  we 
had  not  had  “hot”  hardware  backups,  production  would  have  been  impossible.  Unusual 
failures  or  temporary  “glitches”  in  the  type  of  PC  equipment  that  was  being  utilized  is 
actually  very  common,  and  can  usually  be  corrected  by  rebooting  or  resetting  systems. 
These  are  slow  recovery  procedures,  however,  and  the  value  of  hot  spares  to  address  this 
problem  cannot  be  overstressed.  Production  of  the  NRTR  of  14  April  was  an  unqualified 
success  that  launched  the  NRTR  product  into  visibility  and  demand  as  a  new  and  desirable 
data  product.  Before  he  left  WSMR  after  completion  of  his  mission,  the  Army  TACMS 
PM  had  twenty  full-color  copies  of  an  NRTR,  created  largely  from  his  personal  input.  He 
distributed  these  copies  to  his  personnel,  contractor  representatives,  congressional  staffers 
and  a  host  of  other  interested  parties  ail  over  the  country  where  they  began  making  their 
way  into  formal  reports  and  presentations  of  all  kinds. 


NRTR  PRODUCTION  SYSTEM  COMPONENTS 


The  hardware  and  software  components  of  the  NRTR  produc¬ 
tion  systems  were  selected  from  standard,  off-the-shelf,  per¬ 
sonal  computer  products  that  are  readily  available  from  a 
variety  of  vendors.  The  main  NRTR  assembly  platform  was 
a 48 6, 33  MhzPC  with  8  megabytes  of  RAM  and  a  super- VGA 
color  monitor.  The  main  platform  supported  a  NEC  colormate 
PS  thermal  wax  transfer  printer  with  8  megabytes  of  local 
RAM,  300  X  300  dot  resolution  and  maximum  text  only  print  rate  of  about  1  page  per 
minute.  This  platform  was  running  MSDOS  5.0  and  Microsoft  Windows  3.0  as  operating 
system  and  graphical  user  interface.  The  actual  report  creation  was  accomplished  using 
Aldus  Pagemaker  4.0  which  proved  to  be  an  amazingly  capable  and  versatile  desktop 
publishing  utility.  As  shown  in  figure  1 ,  the  main  system  was  connected  to  the  IGDS  host 
computer  network  where  it  could  take  advantage  of  laser  printing,  mass  storage,  and  other 
large  system  resources  that  were  available  there.  The  graphics  imaging  platform  was  a  3  86, 
25  Mhz  PC  with  2  Megabytes  of  RAM  running  the  same  DOS  and  Wndows  as  the  main 
platform.  This  system. supported  a  Microtek  Scanmaker  600G,  600  x  600  dot  resolution, 
greyscale  scanner  being  controlled  by  the  Photostyler  utility.  The  video  and  photographic 
imaging  platform  was  identical  to  the  graphics  imaging  system.  This  PC  supported  a 
Hauppauge  Wm/TV  video  capture  unit  being  controlled  by  the  Photoshop  utility.  Image 
files  were  transferred  between  the  systems  using  3.5  inch,  1.4  megabyte  floppy  disks. 


CONCLUSION 

With  the  success  of  the  14  April  NRTR,  this  new  kind  of  reporting  has  begim  to  take  its 
place  among  the  many  fine  data  products  produced  at  WSMR.  Each  week  another 
customer  asks  for  a  demonstration  of  the  NRTR  production  system,  and  many  have 
written  the  requirement  for  one  into  their  ORs,  Many  others  have  initiated  working 
dialogues  with  WSMR  to  begin  development  of  templates  to  facilitate  the  production  of 
NRTRs  for  their  tests  in  the  near  future.  The  NRTR  production  team  will  continue  to  refine 
and  enhance  its  reporting  systems  and  has  already  begun  planning  and  specifying  the 
NRTR  system  of  the  future.  A  system  based  on  work-station  technologies  will  allow  the 
integration  of  all  the  NRTR  production  processes  into  a  single  system,  provide  for 
revolutionary  NRTR  production  times  approaching  30  minutes,  and  the  inclusion  of  target 
motion  resolution  and  other  complex  reduced  data  into  the  NRTR.  For  now  the  NRTR 
production  team  will  look  forward  to  serving  its  ever  growing  customer  base  by  providing 
the  very  best  data  products  and  services  available  anywhere  in  the  U.  S.  Army. 
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EPILOGUE  -  After  A  Year  of  Production 

It  has  been  a  little  more  than  a  year  since  the  first  WSMR  NRTR  was  produced  and  a  great 
deal  of  progress  and  change  in  this  rediscovered  arena  continues  to  take  place.  Initially, 
interest  waned  after  the  fanfare  surrounding  the  ATAMCS  NRTR  of  April  1992.  Soon, 
though,  the  word  was  out  and  by  the  end  of  calendar  year  1992  there  were  more  requests 
for  NRTR  template  development  than  could  be  processed.  Since  then  a  steady  stream  of 
test  conductors  have  taken  advantage  of  this  new  product  and  have  come  away  as  satisfied 
NRTR  customers.  About  thirty  NRTRs  have  been  produced  in  the  last  fifteen  months,  for 
some  ten  different  proj  ects  including  Army  TACMS ,  ARMY  Hawk,  Army  ERINT,  MLRS 
TGW  and  SAD  ARM,  Army  Patriot,  and  TMD.  This  translates  to  an  average  NRTR 
production  load  of  two  reports  per  month,  which  is  about  all  the  currently  available 
equipment  and  manpower  can  handle.  The  process  itself  has  been  steadily  refined  and 
tuned  with  several  reports  produced  well  under  the  guaranteed  two  hour  production  time 
with  a  "world  record"  time  on  one  MLRS  NRTR  of  one  hour  37  minutes.  A  new  data 
reduction  process  has  been  recently  developed  to  replace  the  manually  intensive  and 
sometimes  low  resolution  method  of  scanning  axis  and  map  plots  for  importation  into  the 
NRTR  publishing  software.  This  process  takes  digital  graphics  display  data  logged  on  the 
hard  disks  of  the  IGDS  host  systems  (fig.  1 )  and  transmits  them  via  a  fiber  optically  coupled 
network  link  to  a  remotely  located  Decstation  5000  workstation.  This  station  takes  raw 
data  and  produces  map  and  axis  plots  in  Encapsulated  Postscript  format  and  returns  them, 
via  the  network,  to  the  NRTR  assembly  station  where  they  can  be  directly  imported  into 
the  publishing  software.  This  capability  represents  an  important  successful  first  step 
toward  the  total  automation  of  the  reporting  process  and  its  assumption  into  a  truly  merged 
real-time  data  processing,  display,  reduction  and  reporting  system.  Perhaps  the  most 
important  lasting  result  of  this  whole  endeavor  has  been  the  intense  and  widespread 
interest  it  has  spurred  in  speeding  up  and  integrating  data  reporting  in  general.  At  WSMR 
at  least  three  high  level  working  groups  are  moving  on  incorporating  and  expanding  on 
the  concepts  proven  through  these  first  NRTRs  for  processes  throughout  the  Range  in  a 
continuing  effort  to  maximize  customer  service  and  satisfaction  through  better,  more 
timely  and  more  cost  effective  test  and  evaluation  data  products. 
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ATACMS  operation  AB  was  fired  from 
launcher  351  at  LC  33  ,for  intended 
impact  within  the  90  mile  impact  area, 
on  29  May,  1991. 

Launch  was  nominal,  at  an  angle  of 
approximately  55  degrees.  Optical ,  IMU 
and  RADAR  tracking  data  were  nominal 
from  launch. 

Weather  conditions  were  nominal . 


'  V 


Expected  launch  pitch-up 
manuever  was  executed  nominally 
and  a  90  degree  roll  program  was 
performed  at  nominal  TSL.  ATACMS 
achieved  its  expected  apogee  of 
approximately  105, 000 feet  and  proceeded 
as  planned  to  pre-dispense  flight 
manuevers. 
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DISPENSE 


Nominal  ATACMS  operation 
AB  submunition  dispense  event. 

Image  taken  from  \  data 

gathered  near  impact  area. 


DISPERSION 


LAUNCH 


Nominal  launch  of  ATAC  MS 
operation  AB  on  29  May,  1991 

Image  taken  from  optii  >  data 
gathered  at  launch  site 


Nominal  ATACMS  operation 
I  AB  submunition  dispersion. 


Image  taken  from  vide 
data  gathered  near 
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29  May,  1991 

TV\<  KGROC  ND:  Second  of  three  firings  of  early  production  missiles  . 

These  were  identical  to  those  used  in  Operation 
Desert  Storm. 

TFS  1  ()E  fFC  TlV  f.S:  Demonstrate  - 

•  Off-the-side  launch. 

•  Performance  and  accuracy. 

•  New  electronic  safe! arm  fuse  (ESAF). 

\  I  IS  s  I  ( k  t  (X  ikKVihMS 


RANGE 

MISSILE 

TEMP. 

OFF-AXIS 

TOTGT 

WARHEAD 

PAYLOAD 

WARHEAD 

PATTERN 

LLM  POS’N 
(Amils) 

LONG 

A  MB 

L3 

PITCH-UP 
5  deg. 

live' 

MED 

OTS-R 

+  1840 

k  FSI  ITS:  Off-the-side  launch  and  flight  performance  were  as  expected. 
Intended  target  area  was  reached  and  submunitions  were 
dispensed  normally  with  expected  accuracy  achieved. 

ESAF  performed  as  designed.  Mission  was  on  schedule  and 
within  budget.  All  mission  objectives  were  met. 

Preliminary  data  indicates  mission  was  i  FULLY  SUCCESSFUL 

UNCLASSIFIED 
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UNCLASSIFIED 


Army  TACXfS  performed  planned  pitch- 
down  to  level  flight  manuevers  over  the 
intended  target  area  and  proceeded  to  a 
submunitions  dispense  event  as  expected . 


dOMIe 
impact ; 
area  < 


Missile  model  Image  taken  , ;  v 
from  real-tim®graphics  display  ^ 
teing  animated  by  '  P 
telemetry  from  /  ' 

55s.  Army  TACM^  > 

/ 

V' 


\Fl^ht  Path 


) 


Launch 
Complexes 

/  \>fu\  I  \i  MS  submunitions 
I  dispense  and  dispersal  were 
normal  indicating  proper  ESAF 
j  operation.  Submunitions  impacts 
I  were  within  the  intended  target 

f  area  with  predicted  accuracy 

— having  been  achieved. 

DISPENSE 


Table  of  Flight  Parameters 

•  Max.  Altitude 

105,000  ft. 

Max  Velocity  .  . 

1 ,500  ft/sec 

1  Down -Range 
i  Distance 

80  km 

1  Dispense 

1  Altitude 

30,000  ft 

Successful  disf^nse  of  Army  TACMS  submunitions 

UNCLASSIFIED 
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Army  T'ACMS 

Full  Production  Test 
14  April,  1992 

BA<  KGROUM):  Third  firing  of  early  full  scale  production  missiles  . 

This  was  a  Block  I ,  Phase  II  missile  -  indicating 
that  the  warhead  contained  live  M74  bomblets  . 

l  ES  r  OB  IFCTIVES:  To  Evaluate  - 

•  MissilelLaunch  Pod  Assemblies  (MILPAs)  and 
M270  launcher  hardware  and  software  interfaces 
in  an  ojf-the-side  firing  scenario. 

•  Aerodynamic  and  propulsion  performance. 

•  Blast  effects  of  M270  launcher. 

•  Guidance  system  performance. 

•  Warhead  performance  (arming,  dispersion,  dud  n 


\nSSrONRl  01  TREMENTS: 


RANGE 

MISSED 

TEMP. 

OFF-AXIS 

TOTGT 

WARHEAD 

PAYLOAD 

WARHEAD 

PATTERN 

SHORT 

AMB 

NONE 

PI  I  CH-l  P 
!  'teg. 

LI\^ 

LARGE 

RESE  LTS:  Off-the-side  launch  and  flight  performance  were  as  expected. 

Warhead  arming  was  normal.  Intended  target  area  was  reached 
and  submunitions  were  dispensed  normally  with  planned  in¬ 
flight  dispersion  achieved.  Mission  was  on  schedule  and  within 
budget.  All  in-flight  mission  objectives  were  met. 

Preliminary  data  indicates  mission  was  :  SUCCESSFUL 
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54  (\\ 
red  q 
V  law 
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it  imp* 


from  the  missile 


Off-th©-sidelauncnotA^rny  lAOMbTromM^/uiaunwiwr 

normally.  '  ■  I 

Average  weather  conditions  at  the  launch  and  target  ,  ^ 

sites  prevailed  with  light  NE  winds,  less  than  6  Knots,  ••  v;  j  j 
and  unlimited  visibility  down-range.  These  conditions  >  ^  I 
facilitated  full  optical  coverage  of  the  entire  mission.  A  j 


I  ^ 

\\  real-tim© 

"W  'A  graphics  display 

iver  I  \\  being  animated 

;  I  by  telemetry  x 

9&  Degree  j  from  Army 

,<r^ty/  n*H  ITACMS 


Missile  model 
image  taken  from 


! 


\  ’nn,  lALMH  pejformed  planned  pitch- 
down  flight  maneuver  over  the  intended 
target  area  and  proceeded  to  a  submunitions 
dispense  event  as  expected ,  indicating 


further  nominal  guidance,  propulsion 
atid  aerodynamic 

performance.  fmn 


J 


Normal 

Pitch-down 


'  ■  ^ 

Missile  model  image  taken  ^ ^ 
from  real-time  graphics  display 

animated  by  : 

^"^’^SJelemetry  from  /  ' 

r  rny  I A  C  M  V 


;Deefliom 


i  Flight  Patti 


■■ 


Denver  Wit 
Impact  Area 


Proceed  to  Expected 

Submunitions 

Dispense. 


/  ,\rr'!\  I  ACM S  submunitions 
t  dispense  and  in-flight  dispersal  were 
I  normal  indicating  proper  warhead 
I  arming.  Submunitions  impacts  were 
!  within  the  intended  target  area  with 

predicted  flight  accuracy  having  been 
achieved.  Actual  submunition 


dispersal  and  dud  rate  will  be 
determined  through  ground  surveys. 


Successful  dispense  of  Army  TACMS  submunitions 
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GDC  data 
from  RTFS 
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Graph  Start  Time:  7: 11:21 .0289 
Event  Start  Time:  7:11:21.0289 
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o  Data  Analysis  Plans 
o  Consult  on  Math,  Comp.  Sci. 
o  Configure/Develop  Analysis  S/W 
o  User  Training 
o  Systems  Administration 
o  Configuration  Control 
o  Evaluate  S/W  Packages 
for  future  network  expansion 
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